Cleaning up our JavaScript code is easy with default parameters and property shorthands.
In this article, we’ll look at the best practices when designing functions.
Design at the Function Level
We got to design functions properly so that they can be worked on in the future without hassle.
The functions got to have high cohesion. This means that we only want to have relevant code in each function.
Anything unrelated shouldn’t be there.
However, there’re a few kinds of cohesion that aren’t good.
Sequential Cohesion
One of them is sequential cohesion, which means that each operation in a function must be done in a specific order.
We don’t want to get the birth date, then calculate the age and time for retirement afterward for example.
If we have a function that does both, then we should separate them into separate functions.
Communicational Cohesion
Communicational cohesion is another kind of cohesion that isn’t ideal.
Functions that use the same data and aren’t related in any other way shouldn’t be in one function.
For instance, if we have functions that log data and then reset them, then each operation should be in their own function.
Temporal Cohesion
Temporal cohesion is where operations are combined into a routine because they’re all done at the same time.
They encourage us to include code that are unrelated but has to be run at the same time.
In this case, we should separate those unrelated things into their own functions. and then run them under one umbrella function that has to be run at the given time.
For instance, we can write something like the following:
const showSplashScreen = () => {
//...
}
const readConfig = () => {
//...
}
const startUp = () => {
showSplashScreen();
readConfig();
}
Procedural Cohesion
Procedural cohesion is also bad. It means that the operations in a function has to be done in a specified order.
Things like a function to get a name, address, and phone number aren’t good since they aren’t really related, but they’re run in the same function.
It’s better to separate them out into their own functions and call them when needed.
Logical Cohesion
Logical cohesion is when several operations are put into the same function and they’re selected by a control flag that’s passed in.
Since they aren’t related to each other, we shouldn’t have those operations all in one function.
For instance, if we have:
const showSplashScreen = () => {
//...
}
const readConfig = () => {
//...
}
const doSomething = (option) => {
if (option === 'splash') {
showSplashScreen();
} else if (option === 'read-config') {
readConfig();
}
}
Then we shouldn’t have the doSomething function.
Coincidental Cohesion
If a function has operations that have no relationship to each other, then that’s coincidental cohesion.
We should separate any code that isn’t related to each other into their own function.
Good Function Names
We got to name functions with good names. There are a few guidelines to following when we’re naming functions.
Describe Everything the Function Does
A function name should describe what the function does. So if it counts the number of apples, then it should be named something like countApple() .
We should have functions that only do one thing and avoid side effects so we don’t have to describe all of them in the name.
Avoid Meaningless or Vague Verbs
We want verbs that describe what the function does, so verbs like perform , process , or dealWith are too vague.
If a function is counting something then it should have the word like count or a synonym in the name.
Don’t Differentiate Function Names Solely by Number
Number names are not good, something like countApples1 , countApples2 , etc. aren’t good.
They don’t distinguish the difference between them by their name.
Make Function Names as Long as Necessary
A function name should be as long as necessary to describe everything that it does.
This way, everyone reading the code will know what a function does from the name.
Use a Description of the Return Value to Name a Function
If a function returns a value, then it should be named for whatever it returns.
So applesCount is good because we know that it returns the count of apples.
Conclusion
When we define functions, we should avoid various kinds of cohesion that don’t contribute to ease of reading and maintenance.
Also, we should name functions with descriptive names that describe everything that they do.
